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Method for creating a p ©r- to -peer home n twork using common 
group label 

Field of the invention 

5 

This invention relates to a method for creating a network from 
technical devices, e.g. digital electronic consumer devices 
but also computers. 

10 

Background 

In computer technology it is well known to build up a network 
of connected devices for exchanging data and sharing hardware 

15 resources. The separate devices are commonly called nodes- At 
the time being, nodes are usually computers, but can be other 
technical devices, and their interconnections are mainly 
electrically, optically or wireless radio connections. 
Networks can be classified slb being based on either client - 

20 server or peer-to-peer (P2P) architectures. In P2P based 
networks a node is also referred to as a peer. While in 
client- server architectures each node is defined to be either 
client or server, there is no such differentiation in P2P 
networks. Instead, peers include both, server and client 

25 functionalities. P2P technology enables each node to be 

capable of providing services or resources to any other node 
in the network, or use service? or resources provided by any 
other node in the network, 

30 P2P networks are usually not restricted to any special 

applications or underlying network topologies, but can be 
understood as a set of nodes, or peers, which rely on certain 
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aets of specific protocols. It is characteristic for a P2P 
network that the peers communicate directly with other peers, 
so that no central network organization is required. MoBt P2P 
networks support that peers can be connected to the network or 
5 disconnected from the network at any time. 

The mentioned P2P protocols are required for basic network 
organization, such as e.g. discovery of other connected peers, 
offering own services or resources to other peers 

10 (advertising), understanding other peers' advertising 

messages, or allocating connection capacity for establishing 
certain connections to other peers. Also, there are protocols 
that enable a group of peers to cooperate, and thus form a 
peer-group. Such peer-groups are usually used for providing a 

15 common set of services within the peer group. Nevertheless, 
the purpose of a peer-group is not generally defined. A peer 
belonging to a peer-group normally has access to, and can be 
accessed from, all other connected peers of the same group. 
Additionally, each peer may be a member of further peer- 

20 groups. For adding or removing peers to or from a peer group, 
the user is always required to perform certain administrative 
activities. 

Generally only authorized users have access to the peers, or 
25 to the peers' contents, or to released parts of the peers' 
contents, where authorization of the user is achieved by a 
user-specific key, either physical or virtual secret key, e.g. 
password. 



30 



Since peers must be regarded aa individuals, it is necessary 
that each peer can be unambiguously addressed by using an 
identifier. Usually a peer is addressed by using a unique 
label, e.g. a so called Universal Unique Identifier (UUID) . 



Empf.zeit:04/12/2002 12:01 



EmPf.nr.:616 P.012 



4.DEZ.2002 12=01 DTB PATENTS & ADMIN 

PD020110-K6-021129 3 



NR. 351 S. 13/32 



When peers form a peer-group , the peer-group as such usually 
gets a dedicated label, e.g. UUID f which can be used for 
identifying the members of the group. 

The described peer-to-peer networks and mechanisms are in a 
5 detailed manner published e.g. in WO 02/057917 A2 . 

Invention 

10 A problem to be solved by the invention is to reduce the 

required amount of technical administration when establishing 
communication between nodes , with all of said nodeB being 
under control of the same owner, like e.g. in home networks , 
This problem is polved by the method disclosed in claim 1, An 

15 apparatus that utilizes this method is disclosed in claim 10. 

According to the invention, connected peers automatically form 

a P2P group. Peers belonging to the same P2P group can i 

i 

communicate with each other, and access each other's content 
20 or services. Peers from other peer groups can access only if 
said groups are known to each other. Administrational effort 
for the user is also reduced by not requiring user 
authentication for accessing any connected peer, or content 
associated with such peer. As a consequence of using the 
25 invention, a user can have his devices connected to a network 
without having any special networking knowledge « 

Advantageous additional embodiments of the invention are 
disclosed in the dependent claims, the following description 
30 and the figures. 
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Brief description of the drawings 

Exemplary embodiments of the invention are described with 
reference to the accompanying drawings, which show in 

5 

Figure 1 an exemplary peer-to-peer network forming an Owner 
Zone, including an owner's home and other property; 

Figure 2 how two Owner ZoneB are merged into one new Owner 
10 Zone ; 

Figure 3 an exemplary peer-to-peer network forming an Owner 
Zone, which coii^jriBes contents with restricted access; 

15 Figure 4 an Owner Zone and exemplarily two related Trusted 
Zones, where the relationship of trust is bi-directional; 

Figure 5 an Owner Zone and exemplarily a related Trusted Zone, 
where the relationship of trust is unidirectional ; 

20 

Figure 6 two Owner Zones, being Trusted Zones to a third Owner 
Zone, and thus becoming Trusted Zones to each other. 



25 Detailed description of the invention 

A person's home is a private place, not open to the public. 
The home is locked to prevent unwelcome persons from entering, 
but naturally welcome persons, such as family members, may 
30 always enter, and other welcome persons, such as guests, may 
enter at certain times. This corresponds to a relation of 
trust between the owner, or owner group, and the mentioned 
other persons. As a consequence, said trusted other persons 
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usually have access to some, or most, or all, equipment within 
the owners home, including technical devices and mecjia, e.g. 
radio, books, CDs . Nevertheless, there are always some things* 
which may only be accessed by their respective owner, or by 
5 certain groups of persons such as family. Further, it is 

common to lend certain property, such as a book or a music CD, 
to trusted persons . 



The invention maps the described personal relationship to a 
10 technical system, namely a multimedia home network, including 
electronic storage devices, such as e,g. CDs or DVDs, and to 
the connection between multimedia home networks belonging to 
different households. The invention employs the concept of P2P 
networking, and therefore refers to the respective technical 
15 devices as peers , 

Connecting the technical devices of a household to a P2P 
network provides more user convenience, e.g. allows the owner 
to control devices remotely, or to share contents or services 

20 between different devices. For privacy reasons the P2P network 
comprises only peers belonging to the same r household, or 
owner. Since the peers may be located outside the household, 
e,g. in the owners car, garden, or may be portable, the 
terminus "Owner Zone" is used to describe the group of 

25 devices, or peers, which is under control of the same owner, 
or group of owners, e.g. family. Figure 1 shows an exemplary 
Owner Zone, which includes the peers being under control of 
the same owner. The peers Nl,~ f N7 within the owners home H__l 
are connected to a local P2P network P2P_1, the owners mobile 

30 peers N1,N2 are connected to the same P2P network, and other 
peers N6,N7 within another building H_2 belonging to the same 
owner are connected to another local P2P network P2P_2, and 
said two networks P2P 1,P2P 2 are connected to each other. 
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According to the invention the peers with physical access to 
the owner's home network automatically become members of the 
Owner Zone, using known P2P mechanisms such as peer discovery, 
peer resolving, advertising and others. There is no correction 
5 allowed to any other peer outside the Owner Zone, unless any 
of the mechanisms described below is used. 

Further the invention comprises that connections between peers 
can have one of a specified number of states, e.g. internal or 
10 external. The state of a connection can be assigned to said 
connection by using any means, e.g. plug coding or software 
control . 

According to the invention, the Owner Zone is identified with 
15 a unique label, e.g. a Universal Unique Identifier (UUID) . 

Additionally r the peers may be identified with unique labels, 
e.g. UUID, so that the peers belonging to an Owner Zone are 
uniquely identified with a tuple of labels, namely their 
respective unique node label and the Owner Zone's unique 
20 label. These labels are referred to in the following as 

Node_ UUID and Zone_UUID, respectively. Only one group related 
label, or Z©ne_UUID, is assigned to a peer, A peer within an 
Owner Zone can identify all other peers within the same Owner 
Zone by comparing their Zone_UUID to its own Zone_XJUID and 
25 finding that the Zone_UUIDs are identical. In Figure 1 each 

node Nl r -./N7 has a corresponding node label N_ID1,_,N_ID7 and 
a group label Z_ID. 

Different Owner Zones may communicate with each other, or 
30 access each others content or services, when following the 
rules defined below. 

An Owner Zone may contain an informative section, e,g. data 
set, providing information regarding the structure and/or 
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contents of the Owner Zone. This informative section is 
referred to in the following as Zone_Inf o_Data. Analogously, a 
peer within an Owner Zone may contain an informative section, 
e,g. data set, providing information regarding the structure 
5 and/or contents of the peer, which informative section is 
referred to in the following as Node_Inf o_Data. Within the 
Owner Zone, the mentioned informative sections are marked with 
unique labels, e.g. Zone_Inf o_UUID and Node_Inf o_UUID, 
respectively. The mentioned Zone_Inf o_Data may be updated 
10 automatically and may contain information like e.g. Zone_UUTD, 
optional Zone_Name, optional Zone_Service_List or other 
information mentioned below. 



Said optional Zone_Name may be a readable name under which the 
15 Owner Zone is addressed by other Owner Zones, thus partly 

being an alias for the Zone_UUXD, but unlike a ZoneJJUlD not 
necessarily being unique. In case of a first Owner Zone 
addressing a second Owner Zone, and said second Owner Zone 
having a non-unique Zone_Name, it will be neoessary for said 
20 first Owner Zone to specify said second Owner Zone uniquely, 
e.g. by internally mapping said second Owner Zones Zone_ Name 
to said second Owner Zones Zone_UUlD. 

Said optional Zone_Service_I,ist may define which services the 
25 Owner Zone offers to other Owner Zones, if said other Owner 
Zones are permitted to access . The Zone_Service_ List may also 
define in a detailed manner which service shall be accessible 
for which of said other Owner Zones, including the optional 
definition of an access timeframe. 

30 

The mentioned group label, e.g. Zone__UUXD, can be created when 
an owner decides to create an Owner Zone, and it can be 
discarded when the owner decides to discard the respective 
Owner Zone. Especially, when a first peer is connected to a 
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second peer, thus building a new owner Zone, and the peers 
detect that there is no Zone_UUID defined yet for the new 
zone, then both peers negotiate a new Zone_UUID without user 
interaction. Otherwise, when a first peer is connected to a 

5 second peer, and said first peer has no Zone_UUID defined yet, 
but said second peer already belongs to an Owner Zone and 
therefore has a Zone_UUID defined, then the ZoneJJUID of the 
resulting P2P network may remain unchanged, so that said 
Zone_UUID can be transmitted from said second peer to said 

10 first peer. In another embodiment of the invention a new 

Zone_UUip may be negotiated for said resulting P2P network. 
The owner may decide individually, e.g. according to technical 
reasons, whether the ZoneJCJUTD shall be changed or not when 
adding or removing peers. When a single peer is removed from a 

15 peer group, then said peer groups Zone_UUID must be detached 
from said peer. 

If an Owner Zone being accessible from another Owner Zone gets 
a new Zone_UUID, it may be advantageous to store the old 
Zone_UUID, or old Zone_UUIDs, so that said other Owner Zone 
can be informed about the change, or messages from said other 
Owner Zone using said old Zone_UUID are not rejected. The old 
ZoneJJUID can e.g. be stored in the Zone_Inf o_Data section of 
the resulting Owner Zone. 



20 



25 



Advantageously, the described labelling concept for an owner 
Zone can be used to easily merge two or more Owner Zones, as 
shown in Figure 2. When two Owner Zones shall be merged, the 
first Owner Zone OZ_20 being labelled with a Zone_UUID Z_ID A , 
30 and the second Owner Zone OZ_21 being labelled with a 

Zone_UUID Z_ID B , then an exemplary method iB to negotiate a new 
zone label, e.g. Zone_UUIDAB, which may be different from 
Zone_UUlD A and Zone_UUID B , and then assign said new zone label 
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to all peers N22,N23 belonging to said firat Owner Zone OZ_20 
or said second Owner Zone OZ_21. 

When two Owner Zones, here being referred to as Sources, are 
5 merged into a new Owner Zone, then new Zone_ Inf o_Data can be 
generated in order to describe the structure and/or contents 
of the new Owner Zone. Especially, the new Zone_Inf o_Data may- 
contain information about both said Source Owner Zones, e.g* 
their respective zone_UUIDs, Zone_Names and others, and thus 
10 making it possible to track on Owner Zone modifications. 

Since the described method of merging two Owner Zones can be 
applied to any two Owner Zones, at least one of the previously 
described steps is performed, or approved, by the respective 

15 owners of said first and second Owner Zones. 

Further, the described method of merging can be recursively 
applied when more than two Owner Zones shall be merged. In the 
case of merging more than two Owner Zones, the resulting 
Zone_Info_Data may contain information about several, or all, 

20 merged Source Owner Zones . 

Advantageously, the described mechanism for merging enables 
the user to merge all his Owner Zones, which may be in various 
locations, into one Owner Zone. Therefore an Owner Zone is not 
limited to the user's home, as shown in Figure 1. 

25 

Likewise, the described labelling concept for an Owner Zone 
can be used to easily split one Owner Zone into two or more 
Owner Zones . When an Owner Zone, being labelled as e.g- 
Zone_UUID A , shall be split, then an exemplary method is to 
30 calculate a new label, e.g. Zone_UUID B , and then assign Baid 
new label to all peers being intended to belong to the new 
Owner Zone, thus discarding the old zone label for said peers - 
Likewise, the remaining peers, being labelled as Zone_UUID A , 
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can be assigned a new zone label, e.g. Zone_UUID c , if the old 
label Zone_UUID A may not be used any more. 

When an Owner Zone, here being referred to as Source, is split 
5 into two Owner Zones, here being referred to as Targets, the 
owner of the Source Owner Zone will have to specify for the 
associated peers, contents and services one of said Target 
Owner Zones. New Zone_Inf o_Data can be generated for both said 
Target Owner Zones, describing their respective structure 
10 and/ or contents, and especially including information -about 
said Source Owner Zone, e.g. its Zone_ UUID. 

Furthermore, within an Owner Zone there is no need for 
explicit user identification, since every user with access to 

15 any connected peer is implicitly authorized to access the 

whole P2P network. The individual user is anonymous. In other 
words, authentication is related to the peer, not to the user. 
Prom the owner's point of view, this reflects a relation of 
trust existing among all persons within the owner's home, e.g. 

20 family. This does not exclude the possibility of assigning a 

lock mechanism, e.g. password, to certain content or a certain 
service, and thus limiting the number of users having access 
to said content or service. In such a case knowledge of a 
user- independent key, e.g. password, is required to access 

25 said protected content or service, so that user authentication 
is not needed. Figure 3 shows a group of users 30,31,32 having 
access to a number of peers, which are connected via a P2P 
network P2P. For some peers N34 all said users have free 
access, while for other peers N35,N3 6 access is limited to 

30 those users who have, or know, the respective key- A single 

user 32 has sole access to content or service N35, while other 
content or service N3 6 can be accessed by more than one user 
30,31. 
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With the described method for content locking, it 13 likely 
that a super-user function iB required, since it may happen 
that a key gets lost. A super-user function can use arbitrary 
methods, e.g. include the right to delete contents, and thus 
5 can solve the situation of contents being locked and the key 
being lost. 

As mentioned above, communication between different Owner 
Zones is allowed when the following method is used. A first 
owner of a first Owner Zone can express a relation of trust 
towards a second owners Owner Zone, and thus give peers of 
said second Owner Zone access to certain content of said first 
Owner Zone,. When a relation of trust is expressed from a first 
Owner Zone towards another, second Owner Zone, then said 
second Owner Zone is referred to as a ^Trusted Zone* 1 relative 
to said first Owner Zone. This relation of trust can be 
expressed towards any number of other Owner Zones. This may be 
implemented such that an Owner Zone contains a list of other 
Owner Zones which are regarded as Trusted Zones, where said 
other Owner Zones are represented e.g. by their respective 
unique labels* Said list of Trusted Zones may be part of the 
previously mentioned Zone_Inf o^Data . For each of said Trusted 
Zones it can be defined which peers within the Owner Zone may 
be accessed, or which contents or services within the Owner 
Zone may be accessed. 

Figure 4 shows an exemplary Owner Zone 0Z_ 40, consisting of 
peers 42,44 being labelled Z_ID 0 , and two related Trusted Zones 
OZ_41,OZ_42, with the belonging peers N41,N43 and N45 being 
30 labelled Z__ID X and Z_ID 2 , respectively. Peers within said Owner 
Zone OZ_4 0 may connect to peers within said Trusted Zones 
OZ_41,OZ_42 and access content or services from nodes N41,N45. 
Vice versa, peers from said Trusted Zon s OZ_41,OZ_42 can 
connect to peers N42,N44 within said Owner Zone OZ 40 and 
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accesp content or services. Certain content or service on a 
peer N43 within one Trusted Zone 0Z_ 41 is locked as described 
before, and the key is not known in said Owner Zone OZ_40, so 
that the peers from the Owner Zone 0Z — 40 may not access said 
5 content or service. Further, certain content or service on a 
node N44 within the Owner Zone OZ_40 is locked as described 
before, and the key is known in a Trusted Zone OZ_41, so that 
p eers from said Trusted Zone may access said content or 
service. 

10 - 

The described communication method between different Owner 
Zones may include that a number of predefined levels of trust 
exists within an Owner Zone, or globally, and the Owner Zone 
may have assigned for its Trusted Zones certain levels of 

15 trust. If said number of predefined levels of trust contains a 
hierarchy, then said Owner Zone may require for each of its 
contents or services a minimum level of trust. 

Furthermore, it is possible that access between an Owner Zone 
20 and a related Trusted Zone is limited to a certain time frame 
if agreed upon between the owner of the Owner Zone and the 
owner of the Trusted Zone. 

For establishing communication between an Owner Zone and a 
25 related Trusted Zone, it should not be necessary for the 
requesting zone to know more than the Zone_UUID of the 
requested zone, especially it is not necessary to know any 
Node_UUID, or content or service details about the requested 
zone. An exemplary method of establishing contact between 
30 Owner Zones is described in the following. 

When a first peer belonging to a first Owner Zone receives a 
request for communication from a second peer belonging to a 
second Owner Zone, then the request contains the Zone_UUID of 
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said second, requesting Owner Zone, and it may contain a 
specification of what is requested- The first, requested peer 
compares in a first step said Zone_UUlD to its list of Trusted 
Zones, and thus detects if the requesting second peer belongs 
5 to any of these Trusted Zones. If this is the case, then the 
first, requested peer analyses in a second step the received 
request for details of what is requested, and if the requested 
content or service is available. If said details are not 
contained in the first request, said first peer may contact 

10 the second, requesting peer for these details. In a third step 
the first, requested peer may analyse if the second, 
requesting peer is permitted to access the requested contents 
or service, before in a fourth step either admitting or 
rejecting the requested access. Said admitting or rejecting 

15 the requested access is independent from the previously 
described lock mechanism, e.g. password, as long as the 
requesting, second peer can unlock said mechanism, as depicted 
in Figure 4 and described above. 

20 The mentioned relation of trust between Owner Zones can be 
further specified as follows. 

The mentioned relation of trust can be a unidirectional or bi- 
directional relation, meaning that if a firpt Owner Zone is a 
Trusted Zone relative to a second Owner Zone, then said second 

25 Owner Zone can, but needs not necessarily, be a Trusted Zone 
relative to said first Owner Zone. The exemplary relation 
between Trusted Zones shown in Figure 4 is a bi-directional 
relation. It may be implemented such that either of two Owner 
2ones OZ_40,OZ_41 can detect if it is defined as Trusted Zone 

30 relative to the other Owner Zone, and suspend the relation of 
trust if this is not the case . 

A unidirectional relation of trust is depicted in Figure 5, A 
first Owner Zone OZ_S0 is a Trusted Zone relative to a second 
Owner Zone OZ 51, but said second Owner Zone OZ 51 is not a 
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Trupted Zones relative to said first Owner Zone OZ_50, 
Consequently, the peers N54,N55 belonging to the second Owner 
Zone 0Z_51 can access released content or services from the 
firBt Owner Zone OZ_50, but peers N52,N53 belonging to said 
5 first Owner Zone OZ_ 50 may not access content or services from 
the second Owner Zone 0Z_ 51. 

The mentioned relation of trust can be valid explicitly for 
two specified Owner Zones, as in Figures 4 and 5, or may also 

10 include all other Owner Zones, which have a u Trusted Zone" 

relation to either, or both, of them. Figure 6 shows a first 
Owner Zone OZ_60 being a Trusted Zone to a second Owner Zone 
0Z_61 and to a third Owner Zone OZ_62, where a relation of 
trust exists implicitly between the second Owner Zone OZ_ 61 

15 and the third Owner Zone OZ_62 , although they were not 

explicitly defined to be Trusted Zones to each other. In this 
case peers from Owner Zones OZ__61 and OZ_ 62 can access each 
other . 
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Claims 

1. A method for grouping teahnical devices being nodes of a 
network (P2P_1 , P2P_ 2 ) , the nodea being capable of 
5 providing aervices or resources to other nodes of the 

network and using services or resources provided by other 
nodes of the network, wherein a unique label (Z_ID) is 
used for identifying the group, and a unique label 
(N_ID1,~,N_ID7) is used for identifying an individual 
10 node (Nl,_ r N7), characterized In 

- said group label (Z_ID) being created automatically 
when two nodes are connected, and neither of said two 
nodea is already labelled as being member of a group of 
nodes ; 

15 - said group label (Z_ID) being assigned automatically to 

said two nodes; 

- said group label (Z_ID) being assigned automatically to 
other nodes when being connected to said group of 
nodes; and 

- a node having not more than one group label (Z_ID) 
assigned. 

2. Method according to claim 1, wherein said group label 
(Z_ID) . is newly determined and assigned dynamically to 
all nodes belonging to said group of nodes whenever one 
or more nodes are added to or removed from said group of 
nodes . 

3 . Method according to claim 1 or 2 , wherein the nodes are 
under control of the same user. 

4. Method according to any of claims 1-3, wherein two 
different groups of nodes (OZ_20 , OZ_21) may be merged 
into one group, the merging process comprising 
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modification of the affected nodes' group label 
(Z_ID A # Z_ID h ) such that a common group label [Z_lDp^) is 
assigned to the affected nodes (N22,N23) . 

5 5. Method according to any of claims 1-4, wherein a group of 

nodes may be split into two or more groups of nodes, the 
splitting process comprising modification of the affected 
nodes' group label . 



10 S. Method according to claim 5, wherein the modification of 

group labels results in automatically assigning a common 
group label to the nodes of one resulting group of nodes, 
and either automatically assigning another common group 
label to the nodes of the other resulting group of nodes r 

15 or leaving the common group label of said nodes of said 

other resulting group of nodes unchanged. 

7. Method according to any of claims 1-6, wherein 

communication and cooperation between nodes (N41,_,N45) 
20 belonging to different groups of nodes (OZ_40 , OZ_ 42) is 

allowed, if the following conditions are fulfilled, 
namely 

the first condition being that a requesting node belongs 
to a first group of nodes, the group of nodes being 

25 connected to at least one other, second group of nodes, 

the second condition being that said second group of 
nodes can detect unambiguously that the request was 
launched from said first group of nodes, 
the third condition being that for the second group of 

30 nodes it is explicitly allowed to communicate and 

cooperate with the first group of nodes, and 
the fourth condition being that the content or service 
requested by said first group of nodes is available 
within said second group of nodes, and released by said 
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second group of nodes, the release referring explicitly 
to said first group of nodee, or the release referring to 
a number of groups of nodes including said first group of 
nodes . 

5 

8. Method according to claim 7, wherein the third condition 
is further specified such that if a first group of nodes 
(OZ_40) is allowed to cooperate with a second group of 
nodes (OZ_41) , then said second group of nodes (OZ_41) is 

10 also allowed to cooperate with said first group of nodes 

(OZ_4 0) . 

9. Method according to claim 7, wherein the third condition 
is further specified such that if a first group of nodes 

15 (OZ_6l) is allowed to cooperate with a second group of 

nodes (OZ_60) , and the second group of nodes (OZ_60) is 
allowed to cooperate with a third group of nodes (OZ_62) , 
then this constellation leads to that said first group of 
nodes (OZ_61) is allowed to cooperate with said third 

20 group of nodes (OZ_62) , either with or without 

interaction of said second group of nodes (OZ_60) . 

10 . Method according to any of claims 1-9 , wherein said group 
label (Z_ID) is detached automatically from any node when 

25 being disconnected from said group of nodes. 

11. Method according to any of claims 1-10, wherein a 
connection between two nodes has a status, the status 
defining whether both connected nodes belong to the same 

30 group of nodeB or not. 

12. An apparatus for performing a method according to any of 
claims 1-11. 
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Abstract 

An architecture for a multimedia peer-to-peer home network 
(P2P_1, P2P_2) allows the automated definition of peer groups, 
5 or zones, by ueing group labels (Z_ID) , where each peer 
(N1,~.,N7) is capable of automatically identifying whether 
other peers are members of the same group, or of another 
group, and where each peer (N1,~,N7) may freely cooperate with 
other peers of the same group, e.g. exchange information or 

10 share resouraes like storage capacity. 

Using this architecture, it ia e.g. possible that a user who 
is accessing a node within a peer group has also access to any 
other node of the peer group, without being requested for 
authentication. Another characteristic is that other peer 

15 groups (OZ_41) can be defined which have access rights to 

network resources and services (N42,N44) - Advantageously, the 
invention simplifies network creation and operation by not 
requiring the user to have special networking knowledge. 
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Figure 5 
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Figure 6 
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